1. Field of the Invention
This invention relates in general to database management systems performed by computers, and, in particular, to processing objects.
2. Description of Related Art
For nearly half a century, computers have been used extensively by businesses to manage information such as numbers and text, mainly in the form of structured, digital coded data. For example, digital data has been used with airline ticket reservations, bank deposits, insurance claims, and credit card transactions. The average size of business data in digital form is relatively small. For example, a banking record including a customer's name, address, phone number, account number, balance, etc. represents approximately a few hundred characters or a few hundreds or thousands of bits.
Business data, however, represents only a small part of the world's information. With advances in storage, communication, and information processing technologies, other forms of digital data including images, audio, and video have been combined with traditional text and numeric information to form new types of information—multimedia information. Multimedia information is different from general business data since it cannot be fully pre-structured (its use is not fully predictable), and because it is the result of the creation of a human being or the digitization of an object of the real world (e.g., x-rays, geophysical mapping, etc.) rather than a computer algorithm. In addition, the average size of multimedia information may be significantly larger than digital business data.
Numerous applications utilize libraries of digitized data, i.e., digital libraries. For example, digital works are widely used with the Internet, tweening (i.e., identifying animation objects and defining their movements), WebTV, Synchronized Multimedia Integration Language (SMIL) (enabling Web developers to divide multimedia content into separate streams, send them to a user, and have the streams appear as a single multimedia stream), and other network applications based on Transmission Control Protocol/Internet Protocol (TCP/IP) communications and similar communications protocols. As these technologies advance and their costs come down, it becomes more feasible to digitize other types of data, store large volumes of it, and be able to distribute it on demand to users at their place of business or home. However, the speed at which multimedia applications execute may be limited by having to manipulate copies of the same object called for by the applications in sequential order.
At any one time, access to an object in a multimedia database may be limited to a single client or a single work flow application or process. This is true even though the application may need multiple copies of the same object (e.g., copies for memory, for file in a data store, and for application). This sequential processing scheme is the result of a number of fundamental processing limitations.
When multiple copies of an object are being downloaded simultaneously to a single receiving system over a network or other data line, the receiving system may not be able to distinguish between the multiple copies of the same object. For example, User A requests an object and downloads Copy 1 of the object. User B simultaneously requests that same object and receives Copy 2 of the object. Copy 1 and Copy 2 may be downloaded such that a portion of Copy 1 is transmitted over the network, then a portion of Copy 2 is transmitted, etc. Therefore, it is necessary to be able to distinguish between copies of the same object.
A second limitation is that an application program can not distinguish a copy of an object from the original object. For example, User A may download a copy of an object from memory, modify that copy, and upload the copy to back to memory, which also stores the original object. User B may then request a copy of the original object. User B, however, can not distinguish a copy of the object from the original object, and thus, User B may retrieve either the original object or the copy modified by User A. Consequently, User B may download the copy of the object modified by User A instead of downloading the original object. Thus, it is necessary to be able to distinguish between an object and a copy of an object.
A third limitation is that an application may have multiple application threads (i.e., units of work within an application), and each application thread may request different copies of an object, but these retrieve requests cannot be distinguished in conventional systems. Thus, the application can not track which threads have processed particular copies of an object. Even if the application knows that one of the object copies has downloaded, the application will not know which thread the copy is for. Thus, since applications can not track the copies, they can not track when threads have finished manipulating particular copies of objects.
In conventional systems, users and applications receive and process objects sequentially. Consequently, users experience processing delays with the sequential processing system. This problem is amplified when users execute multithreading applications or applications that are required to manipulate large objects and/or numerous objects. For example, the Internet may produce thousands or tens of thousands of copies of the same object. In addition, programs utilizing multiple copies of a single object are more complicated since programmers must be careful to design the program such that all the threads run without interfering with each other. As a result, programs are slower, create unnecessary user inconvenience, and more expensive since programmers must expend extra time and effort to overcome these shortcomings.
Therefore, there is a need in the art to uniquely identify each request to retrieve or store an object to enable multiple users to simultaneously manipulate copies of the same object.
In addition, conventional system process requests for objects by allocating a child process of a library server to process the request such that library server loses control over the child process while the object request is being retrieved. As a result, the child process can not be allocated to another object request until the object has been completely transferred from the object server. More specifically, the request for an object comes from a client server to the daemon process associated with the client server. The request is then transferred from the daemon process to the library server. Then, the request is transferred from the library server to the object server. The object server begins to transfer the object to the client computer via the daemon. After the entire object has been transferred to the client computer, the daemon process notifies the object server that the transfer is complete. The object server then notifies the library server which in turn notifies the daemon process that the transfer is complete. Finally, control of the child process that was allocated to the object request is restored to the library server such that the child process may serve other client requests.
Conventional object retrieval systems have a number of shortcomings. The child process can not handle subsequent tasks until the first transfer is completed and the object server releases the child process of the library server. Only then can the child process be allocated to handle a second object request. Furthermore, a user does not regain control over the object transfer until the object has been transferred and the child process is released. Consequently, each child process processes requests in a synchronous manner in the order in which they are received. As a result, the child process is allocated and idle while the object is being transferred. Moreover, the abilities of a user are restricted until the object is transferred and the child process is released. Thus, conventional systems do not utilize resources in an efficient manner resulting in diminished throughput, performance, and user interaction and control. These shortcomings are further amplified if large objects or a large number of objects are requested since the a child process will be allocated and idle for a longer period time to process these requests.
Accordingly, there is a need in the art to release process resources before a time when an object has been completely transferred such that process resources may be allocated to different tasks during the object transfer and such that a user may perform more tasks during the object transfer.